Conventionally, attachments, such as Microsoft Word®, Microsoft Powerpoint®, Microsoft Excel®, text, images, spreadsheets, presentations, or other documents, are securely transmitted via an email application, such as Microsoft Outlook®, using various methods.
One method relies on an encryption program integrated with the email application itself. Conventionally, a user initiates an email program, creates an email, associates an attachment with the email, and causes the email program to transmit the email, with the associated attachment, to an intended recipient. Prior to transmission, the encryption program integrated with the email application encrypts the email, along with the attachment, and sends the encrypted email to the intended recipient. To access the encrypted email, the intended recipient must have a key, associated with the email sender that enables the decryption of the encrypted email. This method has several disadvantages. First, although it permits a user to encrypt an email transmission efficiently, it requires the recipient to have the same encryption program as that of the sender integrated with the recipient's email application. Second, the encryption of the third party or integrated encryption program may be less effective than using the encryption feature of the application which the user used to originally create the attachment. Third, once the email is decrypted, the attachment can be saved and is no longer subject to encryption, leaving the attachment unprotected at the recipient's computer.
In another available encryption method an attachment is converted from its original format into an encrypted PDF file before transmission. However, this prevents a recipient from directly editing the data contained in the attachment, and as a result, also inhibits efficient collaboration between users.
In another available encryption approach, an attachment is converted to an encrypted zip file or is enclosed within an encrypted PDF envelope. The user then prepares and sends a subsequent email containing the passcode to open the encrypted zip file or PDF envelope to the intended recipient. However, once the zip file or PDF envelope is decrypted, the attachment can be saved and is no longer subject to encryption, leaving the attachment unprotected at the recipient's computer.
Another method uses the encryption feature of the application which the user used to originally create the attachment, but is far more time consuming. Here, a user first encrypts the attachment using the originating application and assigns the encrypted attachment a passcode. The passcode, if pre-stored, has to be separately retrieved from yet another application. The user then opens the email program, creates an email, associates an encrypted attachment with the email, and causes the email program to transmit the email, with the associated encrypted attachment, to an intended recipient. The user then prepares and sends a subsequent email to the intended recipient which contains an indication of the passcode to open the encrypted attachment to the intended recipient. This method, while addressing some of the deficiencies cited above, is cumbersome and requires the user to separately encrypt an attachment in one application and compose multiple emails. In addition, this process is manual and is thus prone to data entry errors (i.e. possibility of a mistyped passcode in a subsequent e-mail), “lost” or “forgotten” passcode errors, in which case even the sender may not be able to open the encrypted document.
What is needed is an encryption system that a) enables a user to send encrypted attachments rapidly and efficiently, b) uses the built-in encryption feature of applications used to create attachments, and also retains the original format of the attachments, c) does not require a user to manually prepare multiple emails, d) does not require the recipient to have the specific encryption program utilized by the sender, and e) eliminates the possibility of “lost” or “forgotten” passcodes rendering the original document inaccessible.